ber software-naming conventions and 
insight into the architecture of the sys- 
tem) , programmers working in pairs, 
adherence to a set of coding standards, 
collaboration of customers and pro- 
grammers, frequent verbal communica- 
tion, frequent releases of software in 
small increments of development, re- 
peated testing of the developmental 
software by both programmers and cus- 
tomers, and continuous interaction be- 
tween the team and the customers. 

The environment in which the Maes- 
tro team works requires the team to 
quickly adapt to changing needs of its 
customers. In addition, the team cannot 
afford to accept unnecessary develop- 
ment risk. Extreme programming en- 
ables the Maestro team to remain agile 
and provide high-quality software and 
service to its customers. However, several 
factors in the Maestro environment have 


made it necessary to modify some of the 
conventional extreme-programming 
practices. The single most influential of 
these factors is that continuous interac- 
tion between customers and program- 
mers is not feasible. The major resulting 
differences between the Maestro and 
conventional versions of extreme pro- 
gramming are the following: 

• Because customers are not always avail- 
able for planning sessions, members of 
the team act on behalf of customers 
during these sessions. 

• In an elaboration of the frequent-plan- 
ning and incremental-release concept, 
releases and planning meetings are syn- 
chronized with a fixed one-week itera- 
tion cycle that facilitates maintenance 
of focus on the development task. 

• Metaphors are occasionally used as 
needed in specific instances, but the 
conventional extreme-programming 


concept of a system metaphor is aban- 
doned as not being helpful. 

• In a departure from the simplest-de- 
sign rule, the team sometimes devel- 
ops software infrastructure that affords 
capabilities, beyond those required in 
the current iteration, that may be use- 
ful later in the development process. 

• In the absence of continuous involve- 
ment of customers and of frequent 
testing of software by customers, there 
is heavy reliance on automated testing. 

This work was done by Jeffrey Norris , Jason 
Fox, Kenneth Rabe, I-Hsiang Shu, and Mark 
Powell of Caltech for NASA’s Jet Propulsion 
Laboratory. Further information is contained 
in a TSP ( seepage 1 ). 

The software used in this innovation is 
available for commercial licensing. Please 
contact Karina Edmonds of the California In- 
stitute of Technology at (626) 395-2322. 
Refer to NPO-41811. 


©Adaptive Behavior for Mobile Robots 

A robotic system attempts to both preserve itself and progress toward a goal. 

NASA’s Jet Propulsion Laboratory, Pasadena, California 


The term “System for Mobility and Ac- 
cess to Rough Terrain” (SMART) de- 
notes a theoretical framework, a control 
architecture, and an algorithm that im- 
plements the framework and architec- 
ture, for enabling a land-mobile robot to 
adapt to changing conditions. SMART is 
intended to enable the robot to recog- 
nize adverse terrain conditions beyond 
its optimal operational envelope, and, in 
response, to intelligendy reconfigure it- 
self (e.g., adjust suspension heights or 
baseline distances between suspension 
points) or adapt its driving techniques 
(e.g., engage in a crabbing motion as a 
switchback technique for ascending 
steep terrain) . Conceived for original ap- 
plication aboard Mars rovers and similar 
autonomous or semi-autonomous mo- 
bile robots used in exploration of remote 
planets, SMART could also be applied to 
autonomous terrestrial vehicles to be 
used for search, rescue, and/or explo- 
ration on rough terrain. 

In SMART, controlling the motion of 
the robot, managing the “health” of the 
robot, and managing resources are con- 
sidered as parts of a free-flow behavior 
hierarchy that autonomously adapts to 
changing conditions. Tasks that must be 
performed in the continuing develop- 
ment of SMART are to provide for safe, 
adaptive mobility on highly sloped ter- 


rain include: 

• Determination of strategies for adap- 
tive reconfiguration and driving that 
are nearly optimal with respect to 
safety and are computationally feasible 
for on-board implementation, 

• Determination of a representation for 
uncertainty in sensing and prediction 
of the state of the robot and its envi- 
ronment, and 

• Determination of resource-manage- 
ment strategies that mitigate such risks 
as those of the loss of battery power 
and/ or drive motors. 

SMART is based largely on a prior ar- 
chitecture denoted Biologically Inspired 
System for Map-based Autonomous 
Rover Control (BISMARC), which, in 
turn is based on a modified free-flow hi- 
erarchy. BISMARC has been used with 
success in a number of different simu- 
lated mission scenarios, wherein it has 
been demonstrated to afford capabilities 
for retrieving objects cached at multiple 
locations, fault tolerance on missions of 
long duration, and preparing terrain 
sites for habitation by humans. BIS- 
MARC includes provisions for all aspects 
of safety, self-maintenance, and achieve- 
ment of goals, as needed to support a 
sustained presence on the surface of a re- 
mote planet. 

BISMARC is organized as a two-level 


system. From stereoscopic images ac- 
quired by cameras aboard the robot, the 
first level generates hypotheses of motor 
actions. The second level processes these 
hypotheses, coupled with external and 
internal inputs, to generate control sig- 
nals to drive the actuators on the robot. 

The figure illustrates the free-flow ac- 
tion-selection hierarchy of BISMARC and 
SMART. The rectangular boxes represent 
behaviors, while the ovals represent sen- 
sory inputs (either fixed, direct, or de- 
rived) . At the top are the high-level behav- 
iors, including Don’t Tip Over, Go to 
Goal, Avoid Obstacles, Preserve Motors, 
Warm Up, Get Power, and Sleep at Night. 
The intermediate-level behaviors 
(Change Center of Gravity, Avoid Obsta- 
cles, Rest, and Sleep) are designed to in- 
teract with both the short-term memory 
(which corresponds to perceived sensory 
stimuli), and the long-term memory 
(which encodes remembered sensory in- 
formation). Control loops are prevented 
by use of temporal penalties, which con- 
strain the system to repeat a given behav- 
ior no more than a predetermined num- 
ber of times. The bottom-level behaviors 
(Tilt Arm, Change Shoulder Angles, 
Move, Rest, Stop, Sleep) fuse the sensory 
inputs and the activations of the higher- 
level behaviors in order to select appropri- 
ate actions for safety and achieving goals. 
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The Free-Flow Action-Selection Flierarchy includes multiple behaviors at different levels. The numerical values shown at several places are examples of 
weights assigned to inputs of behavioral modes. In general, such weights are changed as needed to adapt to changing or previously unknown environ- 
mental conditions. 


Inputs to the behavioral nodes are 
calculated as weighted sums. In BIS- 
MARC, the weights are fixed; conse- 
quently, BISMARC is not capable of 
adaptation to changing conditions or 
to environments outside an original 
world model. In contrast, SMART in- 
cludes a learning mechanism that 


adapts the weights to changing and 
previously unanticipated conditions: 
An algorithm, known in the art as the 
maximize collective happiness (MCH) 
algorithm, adjusts the weights in such a 
manner as to maintain the health of 
the robot while ensuring progress to- 
ward the goal. 


This work was done by Terrance Hunts- 
berger of Caltech for NASA’s Jet Propulsion 
Laboratory. 

The software used in this innovation is 
available for commercial licensing. Please 
contact Kalina Edmonds of the California In- 
stitute of Technology at (626) 395-2322. 
Refer to NPO-40899. 


©Protocol for Communication Networking for Formation Flying 

This protocol provides for adaptation to changing formation geometry and communication 
requirements. 

NASA’s Jet Propulsion Laboratory, Pasadena, California 


An application-layer protocol and a 
network architecture have been pro- 
posed for data communications among 
multiple autonomous spacecraft that are 
required to fly in a precise formation in 
order to perform scientific observations. 
The protocol could also be applied to 
other autonomous vehicles operating in 
formation, including robotic aircraft, ro- 
botic land vehicles, and robotic under- 
water vehicles. 

A group of spacecraft or other vehi- 
cles to which the protocol applies could 
be characterized as a precision-forma- 
tion-flying (PFF) network, and each ve- 
hicle could be characterized as a node in 
the PFF network. In order to support 
precise formation flying, it would be 
necessary to establish a corresponding 
communication network, through which 
the vehicles could exchange position 
and orientation data and formation-con- 


trol commands. The communication 
network must enable communication 
during early phases of a mission, when 
litde positional knowledge is available. 
Particularly during early mission phases, 
the distances among vehicles may be so 
large that communication could be 
achieved only by relaying across multiple 
links. The large distances and need for 
omnidirectional coverage would limit 
communication links to operation at low 
bandwidth during these mission phases. 
Once the vehicles were in formation and 
distances were shorter, the communica- 
tion network would be required to pro- 
vide high-bandwidth, lowjitter service to 
support tight formation-control loops. 

The proposed protocol and architec- 
ture, intended to satisfy the aforemen- 
tioned and other requirements, are based 
on a standard layered-reference-model 
concept. The proposed application proto- 


col would be used in conjunction with 
conventional network, data-link, and 
physical-layer protocols. The proposed 
protocol includes the ubiquitous Institute 
of Elecnical and Electronics Engineers 
(IEEE) 802.11 medium access control 
(MAC) protocol to be used in the data- 
link layer. In addition to its widespread 
and proven use in diverse local-area net- 
works, this protocol offers both (1) a ran- 
dom-access mode needed for the early 
PFF deployment phase and (2) a time- 
bounded-services mode needed during 
PFF-maintenance operations. Switching 
between these two modes could be con- 
trolled by upper-layer entities using stan- 
dard link-management mechanisms. 

Because the early deployment phase of 
a PFF mission can be expected to involve 
multihop relaying to achieve network 
connectivity (see figure), the proposed 
protocol includes the open shortest path 
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